《Day 01：為什麼傳統的「一鍵生成」寫不出好的長篇技術文章？》 的結尾留下了一個還沒被回答的問題。拆分成多個 Agent，解決的是「誰來做」，但拆分之後「先做什麼」的順序要怎麼決定，這個問題當時被刻意留白。今天要正面回答它。

開場：拆分角色之後，混亂為什麼還在

先重述一次 Day 01 結尾丟出的疑問，如果每一個 Agent 依然沿用「先餵資料、再指望 AI 自己整理出重點」的舊習慣，那麼即使角色拆得再細，混亂也只是從一個地方搬到另一個地方，沒有被真正解決。今天要回答的正是這句話，而非另起一個新主題。

想像一個很多人都試過的做法。把寫作拆成兩個步驟，先讓 AI 讀一堆資料整理成大綱，再讓另一個 AI 依照這份大綱把文章寫出來。表面上看起來，這已經是某種形式的分工，一個負責彙整，一個負責撰寫，各自承擔一部分工作。你可能也曾經這樣操作過，把一堆筆記、文件、參考連結一股腦丟給 AI，要求它先幫忙整理出重點，再依照重點展開成文章。

但如果拆解第一步實際在做的事情，會發現問題根本沒有消失。如果第一步依然是漫無目的地把資料全部丟給 AI，期待它自己抓出重點，那麼大綱本身在源頭就已經失焦。資料裡什麼內容顯眼、什麼內容容易被摘要，大綱的重點就長成什麼樣子，而非因為那真的是這篇文章該講的重點。後面接手寫作的步驟，不管多麼認真依照大綱鋪陳，也只是把同一個失焦問題原封不動地往下游搬運，最終產出依然雜亂，只是雜亂的位置從「一次生成」搬到了「兩次生成的交界處」。

這裡可以先點出全篇的核心論點。分工解決的是誰負責哪個步驟，但沒有解決每一個步驟該用什麼順序去思考。如果每一步依然沿用「先看手上有什麼資料，再看能從裡面榨出什麼結論」的舊習慣，角色拆得再細，也無法根治問題，病根從來就在順序本身，而非執行者的多寡。

舊習慣的病根，輸入優先思維

先把這個舊習慣的樣貌講清楚，才知道要對付的敵人長什麼樣子。

不管是人類自己動手寫作，還是指揮 AI 代勞，很多人的直覺工作順序都是這樣的，先收集所有看起來相關的資料，讀完、消化完之後，再回頭想這篇文章到底要講什麼重點、要站在什麼立場。重點的形狀是被資料牽著走決定出來的，而非事先設計好的。這種順序可以稱為「輸入優先思維」，先有輸入，才有結論，結論長什麼樣子取決於輸入裡有什麼。

這個順序聽起來很自然，甚至有點像做研究該有的態度，廣泛蒐集，再歸納結論。但放到寫作場景裡，它有一個根本缺陷。資料本身沒有立場，也不知道這篇文章的讀者是誰、要達成什麼目的。如果先讓資料主導，最終產出的重點會傾向於資料裡最容易被摘要出來的部分，而非讀者真正需要的部分。長篇技術文章尤其容易因此變成資料的堆疊彙整，讀起來像是把好幾份文件的重點接在一起，而非一篇有觀點、有立場的論述。

這裡可以直接扣回 Day 01 已經定案的病灶。內容漂移之所以在多步驟拆分之後依然存在，關鍵在於每個環節都沒有一個穩定的產出目標可以拿來校準自己，單次推理的長度限制只是表面現象。只要角色分工中的任何一個環節還在用輸入優先的方式工作，漂移就會換個位置繼續發生，不會因為多拆了一個步驟就自動消失。

這一節只負責描述問題，不提供解法。解法要留到下一節，用一個明確的名字把它定案下來。

定調：產出優先思維

如果輸入優先思維的問題出在讓資料決定結論，那麼解法的方向很直覺，把順序整個反過來。

先定義這篇文章要給誰看、要主張什麼論點、最終產出物長什麼樣子。把這些定義清楚之後，才回頭決定為了支撐這個產出，需要拉取哪些資料。工作順序與輸入優先思維完全相反，可以稱為「產出優先思維」。

用對比方式會更容易看清楚兩者的差異。輸入優先是資料決定結論，產出優先是目標決定該蒐集什麼資料。

兩者處理的素材可能完全相同，同一批筆記、同一批參考資料，但因為順序顛倒，最終產出的聚焦程度天差地遠。

如果你有實際工程背景，這個順序其實一點也不陌生。工程師在寫測試案例時，經常會先寫下這個功能應該回傳什麼結果，再回頭實作內部邏輯讓測試通過。設計 API 時也是類似的做法，先定義好這個 API 的合約，約定好會收到什麼參數、會回傳什麼格式，再回頭決定內部要怎麼實作才能滿足這份合約。這些做法背後的邏輯都是同一件事，先定義要交付什麼，再回推怎麼做到。

產出優先思維並非專屬於 AI 寫作的新發明，而是把工程領域早已驗證有效的思維方式，遷移到長篇技術文章寫作這個場景。如果你已經習慣先寫測試案例、先定義合約，那麼先定義讀者、論點、產出規格，再回推該蒐集什麼資料這件事，對你來說應該不會太陌生，只是換了一個應用場景而已。

這裡正式標註為系列的錨點定案。後續系列文章只要提及讀者、論點、產出規格與資料蒐集的先後順序，一律稱為「產出優先思維」，不再另創同義詞。

分工只解決一半，順序才是另一半

有了產出優先思維這個對照，現在可以回頭處理一個過於樂觀的想法，以為只要把寫作拆成多個角色分工處理，問題就解決了一半以上。

實情並非如此。即使把寫作拆成多個角色分工處理，如果每個角色內部依然各自用輸入優先的方式工作，也就是每個角色都先看手上拿到的資料，再自己決定要輸出什麼，那麼角色與角色交接的地方就會不斷發生漂移與失焦。原因很直接，沒有任何一個環節事先定義好交出去的東西該長什麼樣子。

具體想像一個畫面。一個角色負責彙整資料、生成初步大綱，另一個角色依照這份大綱寫成正文。如果大綱本身只是資料重點的隨意排列，沒有明確定義這篇文章要對誰說話、要主張什麼立場，那麼下游負責寫作的角色即使認真工作，把大綱裡的每一點都老老實實展開成段落，也只能在一個先天失焦的大綱基礎上繼續放大這個失焦。分工本身不會自動修正上游順序錯誤帶來的損害，它只是誠實地把上游的錯誤原樣呈現出來，甚至因為下游寫得更詳細，讓原本模糊的失焦看起來更像是一篇完整的文章，反而更難察覺問題出在哪裡。

這裡可以收束出全篇最核心的主張。角色分工回答的是「誰來做」，產出優先思維回答的是「先做什麼、以什麼為依歸做」。這是兩個正交的維度，一個決定工作怎麼切分，一個決定每一份工作該用什麼順序展開。缺少任一維度，系統都無法真正解決 Day 01 揭露的病灶。只做到角色分工而沒有產出優先思維，得到的是分工整齊卻依然失焦的產出，反過來，如果只有產出優先思維而沒有角色分工，依然會撞回 Day 01 描述的那些問題，因為單一次推理裡同時要處理宏觀邏輯與微觀查證，順序想得再清楚也無法解決注意力被迫來回切換的困境。兩者必須同時具備。

單一職責 Agent，把產出優先思維嵌進分工原則本身

心法定案之後，還缺一塊拼圖。產出優先思維說的是先定義要交出什麼，但這件事要怎麼落實到角色分工的具體設計方式上，需要另一個原則來銜接。

這個原則可以稱為「單一職責 Agent」。每一個 Agent 只承擔一種明確定義的認知任務，不得跨界承擔其他 Agent 的職責。這個定義的重點在於「明確定義」與「不跨界」，一個角色如果職責模糊、什麼都能做一點，或是同時身兼好幾種性質不同的任務，就不符合這個原則，即使它掛著一個聽起來很專業的名字。

單一職責 Agent 與產出優先思維之間的關係，並非兩件各自獨立的事，而是互為前提。一個 Agent 若要真正做到只承擔一種任務，前提是這個任務本身的產出規格必須先被清楚定義出來，這份工作交出去的東西究竟該長什麼樣子、符合什麼格式、回答了什麼問題。如果連這個角色該交出什麼都說不清楚，職責邊界自然也劃不清楚，因為職責邊界本來就是依照這個角色該產出什麼畫出來的。反過來說，如果一個角色的產出規格已經定義得很清楚，職責範圍自然也會跟著收斂到很明確的形狀，不容易發生模糊或越界的情況。

這個原則對軟體工程背景的讀者來說，同樣不陌生。一個函式或一個模組應該只做一件事，並且把它的輸入輸出定義清楚，這是工程設計裡行之有年的紀律。單一職責 Agent 只是把這套已經驗證有效的紀律，遷移到寫作場景裡的角色分工設計上，不是憑空發明的新規則。

這一節只定義原則本身，以及它和產出優先思維之間互為前提的關係。至於這個原則具體會拆出哪幾種 Agent、各自的邊界如何劃分，這些問題留待後面才會展開。

這裡同樣正式標註為系列的錨點定案。後續系列文章只要提及個別 Agent 的職責範圍與邊界劃分原則，一律稱為「單一職責 Agent」，不再另創同義詞。

小結：心法就位，分工的具體樣貌還沒揭曉

今天要重申的核心論證是這樣的。角色分工要真正解決 Day 01 揭露的病灶，必須同時具備兩個條件。第一，每個角色的工作都遵循產出優先思維，先定義要交出什麼，再決定要準備什麼資料。第二，每個角色都符合單一職責 Agent 的原則，只承擔一種明確任務，不跨界處理其他角色的工作。兩者缺一不可，少了產出優先思維，分工只是把混亂搬到下游，少了單一職責 Agent，產出優先思維也找不到一個明確的執行單位可以落地。

今天定案了兩個心法層級的錨點，產出優先思維與單一職責 Agent。兩者合起來說明了角色分工要真正發揮作用，必須先把要交出什麼定義清楚，再讓每個角色只承擔一種不跨界的任務。

但心法就位不等於藍圖就位。長篇技術文章的創作過程具體要拆成哪些角色，每個角色的職責邊界劃在哪裡，彼此之間又要如何交接工作成果，這些問題今天都還沒有答案。這張完整的分工藍圖，將在 《Day 03：拆解寫作工作流，規劃、撰寫、視覺、審查的四種角色》 正式揭曉。